paint-brush
Preguntas frecuentes para un gerente de contratación de ingeniería de software - Parte 3 de 5: Portafolios y GitHubspor@alishahnovin
294 lecturas

Preguntas frecuentes para un gerente de contratación de ingeniería de software - Parte 3 de 5: Portafolios y GitHubs

por Alishah Novin10m2022/08/02
Read on Terminal Reader
Read this story w/o Javascript

Demasiado Largo; Para Leer

Con más de 10 años de experiencia como gerente de contratación de ingenieros de software, compilé una lista de las muchas preguntas recurrentes que recibí de los solicitantes de empleo.

People Mentioned

Mention Thumbnail

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Preguntas frecuentes para un gerente de contratación de ingeniería de software - Parte 3 de 5: Portafolios y GitHubs
Alishah Novin HackerNoon profile picture

Las entrevistas técnicas han evolucionado mucho desde que pasé de ser ingeniero de software a gerente de ingeniería. Particularmente en la era posterior a Covid, ha habido un mayor énfasis en la persona, lo que creo que es un cambio importante y bienvenido.


Durante la década de entrevistar a cientos de programadores, también tuve el placer de trabajar con varios bootcamps, universidades y cientos de buscadores de empleo individuales en LinkedIn. A través de todos los cambios en los últimos años, a través de los diversos lugares y medios, algo se mantuvo constante: las preguntas que me hacen.


Con eso en mente, pensé: ¿por qué no hacer preguntas frecuentes desde mi perspectiva como gerente de contratación?

Si bien esta es mi perspectiva, se basa en años de observación y datos de apoyo. Pero dicho esto, el consejo no es un hecho. Puede estar en desacuerdo con ciertos puntos, y eso está bien. Las opiniones con las que no estamos de acuerdo nos permiten comprender mejor nuestros propios puntos de vista. En el mejor de los casos, espero que estas respuestas te ayuden a conseguir el trabajo de tus sueños. En el peor de los casos, espero que te ayuden a formar tus propias ideas sobre cómo abordar tu carrera.


En esta parte, me concentraré en las preguntas que he recibido sobre portafolios y GitHubs .




En carteras

  1. ¿Realmente necesito un portafolio/sitio web?

    Realmente depende, pero estoy enormemente a favor de ellos. Los currículums me muestran tu lado profesional. Los portafolios muestran tu personalidad, tus intereses. Le dan a los gerentes de contratación un sentido diferente de quién es usted y cómo busca crecer.


    Por supuesto, no todos necesitan uno, o tienen el deseo de construir uno. Conozco a muchos codificadores exitosos que no tienen un portafolio/sitio web y nunca lo necesitaron. De hecho, la mayoría de los desarrolladores que conozco no tienen uno. Y si ese es el caso, ¿por qué presiono por ellos?


    La respuesta simple es que es un juego de probabilidades. La contratación de tecnología es un mundo salvaje en este momento: hay mucha demanda, muchos candidatos, es ultracompetitivo, pero la gente también tiene dificultades para encontrar trabajo. Un portafolio no te garantizará conseguir un trabajo, pero te dará una ventaja significativa sobre otros candidatos siempre que lo hagas bien.


    Su cartera no tiene que ser una gran empresa, y debido a que los beneficios superan con creces los costos, creo que construirlos tiene mucho sentido. Debido a que los portafolios son personales, creo que las personas se sienten abrumadas por "el arte de lo posible" , y luego nunca producen nada.


    Si crea su cartera de manera iterativa, comenzando de a poco y expandiéndose solo según sea necesario y tenga tiempo, es una excelente manera de establecerse.


    Para obtener más información, aquí hay algunos recursos sobre cómo crear una cartera excelente:

  2. ¿Qué pongo en mi cartera?

    En primer lugar, conoce a tu audiencia. Su cartera no es para sus amigos, su familia: su audiencia real es el gerente de contratación. Desea enfocar su contenido de manera que sea fácil de consumir, así que concéntrese en cómo presenta las cosas. Piense en ello como su currículum + creatividad. Agregue algo de estilo, pero hágalo utilizable.


    Soy un gran admirador de las imágenes rápidas que ayudan a alguien a obtener una impresión de lo que puede hacer, ya sea enumerando sus idiomas, enumerando sus años de experiencia con cada uno, enumerando sus proyectos, hágalo visual, interactivo, pero no agregue cualquier "fricción" a él tampoco. Con eso quiero decir, las presentaciones de diapositivas lentas que requieren que me siente y espere a que las cosas aparezcan y desaparezcan no es un buen enfoque. Haz una lista de todo para que pueda verlo, consumirlo y seguir adelante.


    Otra cosa es: darle un poco de vida. No haga que parezca que lo construyó hace años y se olvidó de él: agregue algunos elementos dinámicos, para que siempre luzca fresco. Haga que se alimente de su twitter, o simplemente cree una pequeña integración en su blog, o simplemente tenga un "micro-blog" que mantenga a las personas actualizadas sobre lo que está trabajando.


    El contenido principal está en torno a sus proyectos. Qué has construido, qué estás construyendo. Incluya escritos agradables que cubran lo que ha aprendido, lo que lo desafió, lo que lo enorgullece, lo que haría mejor. Impactos y Resultados.


    Esta plantilla que hice es lo mínimo que debe enumerar. Todo es estático, tiene elementos de diseño mínimos, pero realmente ayuda a un gerente de contratación a comprender quién es usted:




    Como puede ver, las cosas clave para enumerar son:

    • La pila tecnológica y las metodologías que conoce

    • una minibiografía

    • Enlaces importantes: a su GitHub, su currículum, su LinkedIn,

    • Visuales rápidos que resumen su carrera

    • Proyectos, con la pila de tecnología y enlaces a GitHub

    • Secciones "en vivo" que puede actualizar fácilmente con lo que está trabajando / leyendo (actualícelos tal vez una vez al mes).


    Como dije antes, le tomará más de un fin de semana construir algo como esto y ayudará a darle a su aplicación esa ventaja adicional.


    A medida que creces en tu carrera, actualizarlo se vuelve bastante trivial.


  3. ¿No puedo simplemente usar GitHub?

    Puedes - sí. Pero no descargues tus proyectos en GitHub y termines el día. Cree una página de inicio de GitHub adecuada y utilícela como su cartera.


    Puedes construirlo usando GitHub Pages , solo sigue los mismos principios que mencioné anteriormente.


  4. ¿Debo obtener mi propio nombre de dominio?

    No necesita uno, pero tener su propio dominio es como tener su papelería. Es un buen toque.


  5. ¿Qué tan personal debo ser en mi sitio web? ¿Debo compartir fotos familiares? ¿Recetas? ¿Una foto de mi salamandra mascota?

    Comparta lo que le gusta; en última instancia, conozca su propósito. No pretende ser un perfil de Facebook, pero tampoco pretende ser un perfil de LinkedIn. Su audiencia sería un gerente de contratación.


    Ayúdalos a conocer tu personalidad social pero profesional .


  6. ¿Debería preocuparme por el SEO, los rangos de página, etc.?

    No. Eso es más de hacerlo. Mantén tu HTML limpio, pero tampoco te estreses.


    Solo haga lo que sea más relevante para los roles que persigue: si es un desarrollador de Node, cree cosas con Node. Si es SEO, entonces seguro: optimícelo para los motores de búsqueda. Pero si eres un ingeniero de SQL, es probable que no te juzgue por tus habilidades en HTML/CSS.


  7. ¿Debo incluir un currículum descargable / mi correo electrónico?

    En última instancia, eso depende de usted, pero si incluye cualquiera de los dos, tenga cuidado con la información que hace pública. Tal vez elimine su número de teléfono de su currículum descargable. Asegúrese de que su proveedor de correo electrónico filtre el spam.


    Alternativamente, dirija a las personas a su LinkedIn o incluya un formulario donde puedan ponerse en contacto con usted.

En GitHub

  1. ¿Cómo debería ser mi página de destino de GitHub?

    Escriba un archivo Léame simple que imite el contenido de su cartera. Sencillo, limpio y elegante. Querrá mantenerlo actualizado, así que asegúrese de construirlo de tal manera que requiera el mínimo esfuerzo.


    Fije sus proyectos e incluya enlaces importantes a su cartera/LinkedIn.


    Sin embargo, no es necesario exagerar. Si bien hay algunos increíbles, creo que mantenerlo simple es el mejor enfoque (a menos que esté creando esto en lugar de una cartera).

    Como referencia, aquí está mi propia página de inicio de GitHub: GitHub - Alishah Novin


  2. ¿Necesito realmente construir mis páginas de proyecto?

    Asegúrese de tener un archivo Léame. Puede hacer mucho con ellos, y me acercaría a ellos como si estuviera escribiendo para otros desarrolladores (pensando en secreto en el gerente de contratación).


    En un entorno profesional, a menudo necesitará explicar qué hace un producto o función, cómo debe usarse, cuáles son sus limitaciones, etc. Esta es su oportunidad de mostrárselo a un gerente de contratación, así que mientras lo escribe para otros desarrolladores que consumirán su proyecto, recuerde que su audiencia real es el gerente de contratación.


    Proporcione una descripción general, proporcione capturas de pantalla, proporcione un registro de cambios. Documente las cosas para demostrar que puede comunicar conceptos técnicos.


    Como otro ejemplo, como referencia, está mi página de GitHub para código/colisión . Tenga en cuenta que hay muchos mejores, pero construí esta página para dar una idea de cómo debería ser su mínimo.


    No se limite a cargar su proyecto y llamarlo un día.


  3. ¿Debo preocuparme por la calidad de mi código o cuánto he comentado?

    Su código será revisado, sí. La gente buscará comentarios y los leerá. Es probable que no entren en detalles, pero querrá asegurarse de que sus archivos de código estén presentables.

    Trátelo como si fuera un proyecto real. Especialmente si ha mejorado un algoritmo, asegúrese de que aparezca en sus comentarios de confirmación.

    Los gerentes de contratación probablemente no se sentarán allí y diseccionarán su código para asegurarse de que sea hipereficiente, pero lo observarán para tener una idea de lo que sabe o no sabe.

    Tenga cuidado con el exceso de ingeniería o la escritura de un código de espagueti demasiado complicado. De hecho, intente reducir cualquier olor a código.

    Un gran recurso que me gusta y que te ayuda a escribir un código súper presentable es Refactoring and Design Patterns .


  4. ¿Debo incluir mi GitHub en mi currículum?
    Sí. Como URL, no como texto vinculado. Los currículums se imprimen y, que yo sepa, no se puede hacer clic en un enlace en papel.


  5. ¿Debo incluir mi GitHub en mi LinkedIn?
    Sí.


  6. ¿Debo preocuparme por cuán activo es mi GitHub?
    No. Esta es una presión innecesaria que los codificadores nos ponemos a nosotros mismos. Queremos el codiciado muro verde. Si bien tener varias confirmaciones diarias es excelente, no te garantizará un trabajo. Preocúpate menos por tener una alta frecuencia de confirmaciones y, en cambio, preocúpate más por tener confirmaciones impactantes: proyectos que muestren tu evolución y crecimiento como desarrollador. Eso puede ser sólo unos pocos al mes.

    Por otro lado, asegúrese de no tener toneladas y toneladas de proyectos abandonados o sin terminar. Tenga ideas completas: todas pueden estar en varias etapas de finalización, pero no tenga más de 2 proyectos que no estén en una etapa de MVP. Termina lo que empiezas. Sacrifica la novedad por los matices.


  7. ¿Debo incluir proyectos de curso?

    El trabajo del curso solo es bueno en ausencia de sus propios proyectos. Mantenga el trabajo del curso visible hasta que tenga sus propios proyectos en los que apoyarse, luego oculte las tareas.


  8. ¿Debo incluir todos mis proyectos?
    Solo incluya aquellas que sean ideas completas y completas; no tienen que ser productos completos. Me gusta distinguir entre proyectos y productos. Un "Producto" está creando un clon completo de Twitter/Facebook. El tamaño y el alcance de los productos pueden ser tan grandes que es posible que nunca los completes, y no te servirán de mucho porque abrumarán al gerente de contratación.

    Los "proyectos" son unidades de trabajo más discretas. Una biblioteca. Un experimento.

    Definitivamente deberías compartir proyectos e incluir en tu redacción de qué se trataban y qué intentaste lograr.

    Incluya "Productos" siempre que estén lo suficientemente avanzados como para que puedan valerse por sí mismos. Si nunca pasó de la pantalla de inicio de sesión, no la incluya.

    Reiteraré* (en realidad, solo estoy copiando y pegando)*: asegúrese de no tener toneladas y toneladas de proyectos abandonados o sin terminar. Tenga ideas completas: todas pueden estar en varias etapas de finalización, pero no tenga más de 2 proyectos que no estén en una etapa de MVP. Termina lo que empiezas. Sacrifica la novedad por los matices.




Vale la pena señalar que todas estas respuestas son mis propios puntos de vista subjetivos que he generalizado en empresas pequeñas y grandes. Reflejan mi estilo personal, pero también felizmente presentaré que tampoco son 100% correctos. Es lo que funcionó para mí, pero me encanta recibir aportes y opiniones de los demás.


¿Tienes alguna pregunta que no haya respondido? ¡Conéctate conmigo en LinkedIn y envíamelos!


También publicado aquí .